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Abstract 
Two common ways to communicate timezone information are POSIX 1003.1 
timezone strings and timezone database names. This memo specifies 


DHCP options for each of those methods. The DHCPv4 time offset 
option is deprecated. 
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Introduction 


This memo specifies a means to provide hosts with more accurate 
timezone information than was previously available. To do this we 
make use of two commonly used methods to configure timezones: 


o POSIX TZ strings 
o Reference to the name of the time zone entry in the TZ Database 


POSIX [1] provides a standard for how to express timezone information 
in a character string. Use of such a string can provide accuracy for 
at least one transition into and out of daylight saving time (DST), 
and possibly for more transitions if the transitions are regular 
enough (e.g., "second Sunday in March at 02:00 local time"). 

However, for accuracy over longer periods that involve daylight- 
saving rule changes or other irregular changes, a more detailed 
mechanism is necessary. 


The TZ Database [7] that is used in many operating systems provides 
backwards consistency and accuracy for almost all real-world 
locations since 1970. The TZ database also attempts to provide a 
stable set of human readable timezone identifiers. In addition, many 
systems already make use of the TZ database, and so the names used 
are a de facto standard. Because the TZ database contains more 
information, one can heuristically derive the POSIX information from 
a TZ identifier (see [10] for an example), but the converse is not 
true. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [2]. 


1. Related Work 


Dynamic Host Configuration Protocol (DHCP) [3] provides a means for 
hosts to receive configuration information relating to their current 
location within an IP version 4 network. [5] similarly does so for IP 
version 6 networks. RFC 2132 [4] specifies an option to provide 
client timezone information in the form of an offset in seconds from 
UTC. The information provided in that option is insufficient for the 
client to determine whether it is in daylight saving time, and when 
to change into and out of daylight saving time. In order for the 
client to properly represent local wall clock time in a consistent 
and accurate fashion the DHCP server would have to time lease 
expirations of affected clients to the beginning or end of DST, thus 
effecting a self stress test (to say the least) at the appointed 
hour. 
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In addition, an offset is not sufficient to determine the actual 
timezone in which a client resides, and thus there is no means to 
derive a human readable abbreviation such as "EST" or "EDT". 


VTIMEZONE elements are defined in the iCalendar specification [9]. 
Fully specified they provide a level of accuracy similar to the TZ 
database. However, because there is currently no global registry of 
VTIMEZONE TZIDs (although one has been proposed; see [8]), complete 
accuracy requires that a full entry must be specified. To achieve 
the same information would range from 300 octets upwards with no 
particular bound. Furthermore, at the time of this writing the 
authors are aware of no operating system that natively takes 
advantage of VTIMEZONE entries. It might be possible to include an 
option for a TZURL. However, in a cold start environment, it will be 
bad enough that devices are stressing the DHCP server, and perhaps 
unwise to similarly afflict other components. 


2. New Timezone Options for DHCPv4 
The following two options are defined for DHCPv4: 


PCode Len TZ-POSIX String 


TCode Len TZ-Database String 


| 101 | N | Reference to the TZ Database | 
+----- +----- rr rr rr rr rr rr rr rr rr rr rr rr rr rn + 


Per RFC 2939 [6], IANA allocated PCode (100) and TCode (101). 


Len is the one-octet value of the length of the succeeding string for 
each option. 


The string values that follow Len are described below. Note that 
they are NOT terminated by an ASCII NULL. 


3. New Timezone Options for DHCPv6 
The semantics and content of the DHCPv6é encoding of these options are 
exactly the same as the encoding described for DHCPv4, other than 


necessary differences between the way options are encoded in DHCPv4 
and DHCPv6. 
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Specifically, the DHCPv6 new timezone options are described below: 


0 1 2 3 
DZ GGA GA: 6 ZL EE OZ ZA A GE 7 8 9 0, d 23 dk GA 6 7-8 GA d 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| OPTION_NEW_POSIX_TIMEZONE | option-length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TZ POSIX String | 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
option-code: OPTION_NEW_POSIX_TIMEZONE (41) 


option-length: the number of octets of the TZ POSIX String Index 
described below. 


0 d 2 3 
DZ ZZ GZ: E GGE 9 OT d d GGE A EG OA 2 3 d ZO E FB 9 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| OPTION_NEW_TZDB_TIMEZONE | option-length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TZ Name | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


option-code: OPTION_NEW_TZDB_TIMEZONE (42) 


option-length: the number of octets of the TZ Database String Index 
described below. 


4. The TZ POSIX String 


TZ POSIX string is a string suitable for the TZ variable as specified 
by [1] in Section 8.3, with the exception that a string may not begin 
with a colon (":"). This string is NOT terminated by an ASCII NULL. 
Here is an example: 


EST5EDT4,M3.2.0/02:00,M11.1.0/02:00 


In this case, the string is interpreted as a timezone that is 
normally five hours behind UTC, and four hours behind UTC during DST, 
which runs from the second Sunday in March at 02:00 local time 
through the first Sunday in November at 02:00 local time. Normally 
the timezone is abbreviated "EST" but during DST it is abbreviated 
"EDT I . 


Clients and servers implementing other timezone options MUST support 
this option for basic compatibility. 
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The TZ Name 


TZ Name is the name of a Zone entry in the database commonly referred 
to as the TZ database. Specifically, in the database’s textual form, 
the string refers to the name field of a zone line. In order for 
this option to be useful, the client must already have a copy of the 
database. This string is NOT terminated with an ASCII NULL. 


An example string is Europe/Zurich. 


Clients must already have a copy of the TZ Database for this option 
to be useful. Configuration of the database is beyond the scope of 
this document. A client that supports this option SHOULD prefer this 
option to POSIX string if it recognizes the TZ Name that was 
returned. If it doesn’t recognize the TZ Name, the client MUST 
ignore this option. 


Use of the Timezone String(s) Returned from the Server 


This specification presumes the DHCP server has some means of 
identifying which timezone the client is in. One obvious approach 
would be to associate a subnet or group of subnets with a timezone, 
and respond with this option accordingly. 


When considering which option to implement on a client, one must 
choose between the TZ Name, which should be easier for users to 
configure and which provides accuracy over longer historical periods, 
and the TZ POSIX string, which does not require regular updating of a 
copy of the TZ Database. The TZ Name is better for most uses, in 
particular those cases where the timezone name might persist ina 
database for long periods of time, but the TZ POSIX string may be 
more suitable for small-footprint applications that are expertly 
maintained. 


So that clients need not request both options, servers who implement 
either timezone option SHOULD implement the other one as well. This 
association can be established by the server’s administrator. A 
basic server can transmit option values to the client without parsing 
or validating them. A more advanced server might have a copy of the 
TZ database and validate TZ names against this copy, or derive TZ 
POSIX strings heuristically from TZ names to simplify administration. 


As a matter of practicality, the client will use this information at 
its discretion to configure the current timezone in which it resides. 


It will periodically be necessary for a DHCP server to update the 
timezone string, based on administrative changes made by local 
jurisdictions (say, for instance, counties in Indiana). While the 
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authors do not expect this to be a lower bound on a lease time in the 
vast majority of cases, there may be times when anticipation of a 
change dictates prudence, as certain governments give little if any 
notification. 


The effect of a changed timezone on client applications is not 
specified by this memo, but it may be helpful to note common problems 
in this area. Often, client applications consult the timezone 
setting only during process initialization, or inherit the setting 
from a parent process, so existing processes on a client may ignore a 
timezone change returned from the server. Sometimes it is normal and 
expected for processes on the same client to have different timezone 
settings (e.g., remote logins), and so client implementations should 
consider these ramifications of changing timezone settings of 
existing processes. 


7. The New Timezone Option and Lease Times 


When a lease has expired and new information is not forthcoming, the 
client MAY continue to use timezone information returned by the 
server. This follows the principle of least astonishment. 


8. Deprecation of Time Offset Option 


Because this option provides a superset of functionality to the 
previous IPv4 time offset option (tag 2), and in order to maintain 
consistency between IPv4 and IPv6 implementation, the older option is 
deprecated. Current implementations that support the time offset 
IPv4 option SHOULD implement this option also. Other implementations 
SHOULD implement this option, and SHOULD NOT implement the time 
offset IPv4 option. As a matter of transition, clients that already 
use the time offset option MAY request the time offset option and the 
timezone option. 


9. Security Considerations 


An attacker could provide erroneous information to a client. It is 
possible that someone might miss a meeting or otherwise show up 
early, or that heavy machinery or other critical functions might act 
at the wrong time or fail to act. If clients have job processing 
tools, such as cron that operate on wall clock time, it is possible 
that certain jobs could be triggered either earlier or later, or even 
repeated or skipped entirely if scheduled during a DST transition. 

In such cases, the client operating system might do well to confirm 
timezone changes with a human. 
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10. 


dd 


Clients using the POSIX option should beware of any time zone setting 
specifying unusual characters (e.g., control characters) in the 
standard or daylight-saving abbreviations, as this might well trigger 
security-relevant bugs in applications. 


Clients using the POSIX option should also be suspicious of any 
timezone setting whose UTC offset exceeds 25 hours (the POSIX limit, 
if the default daylight-saving offset is used). As of this writing, 
the maximum UTC offset is 14 hours in practice, but governments may 
extend this somewhat in the future. 


IANA Considerations 


The IANA has allocated DHCPv4 and DHCPv6 option codes for this 
purpose and references this document. 


The IANA has annotated the time offset IPv4 option (tag 2) as 
deprecated, with a reference to this document. 
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